Transactional system with peer-to-peer distributed architecture for exchanging units of account

ABSTRACT

A transaction system based on a distributed peer-to-peer computer architecture, said system involving transactions generated by users by means of wallets and allowing the transfer of units of account by feeding inputs from outputs, each transaction (called downstream transaction) having an input directly or indirectly referring to an output of an upstream transaction (or several inputs each referring to an output of a respective upstream transaction) and having an output specifying the number of units of account and an address of a recipient. 
     The system comprises means for connecting an input of a downstream transaction to an output of an upstream transaction as a function of matching rules between a code computed on all or part of the content of the downstream transaction and a check code contained in the upstream transaction, or conversely, 
     The system further comprises means for propagating a contract, predetermined at an upstream transaction, to a downstream transaction having an input connected to the output of said upstream transaction, said contract being executable on a context for establishing allocation constraints of the output(s) of the downstream transaction, such allocation being authorized only if the constraints are met.

FIELD OF THE INVENTION

This invention relates to the field of protocols, such as Bitcoin, forpeer-to-peer transactions of units of account, in a decentralized manneron a network such as the Internet, without the intervention of a trustedthird party, using electronic signature by means of a software and/orhardware “wallet”.

BACKGROUND OF THE INVENTION

The expressive power of Bitcoin is considerable. Indeed, as particularlydescribed and illustrated Mike Hearn in 2013[https://en.bitcoin.it/wiki/Contracts], one can issue a firsttransaction which, while offering the advantage of depositing/lockingthe funds that are inputted therein (from the fact of being insertedinto the blockchain), represents a conditional payment for a secondtransaction, where said condition can consist in requiring signatures tobe provided within said second transaction and can even contain “ORs”.One can thus express transactions of the type “payment of 1 bitcoin,valid from . . . , on signatures by . . . and . . . or . . . ”.

However, once the first transaction is inserted into the blockchain, thefunds are thus locked and said condition cannot be changed. The only wayto make it evolve—for example if later new signatures are required inthe condition—is by making the first transaction to pour the funds intoa new first transaction having the desired condition. For example, thecondition for the payment of a first transaction being “on signing by Xor Y”, the money will have to be poured into another first transactionhaving the condition “on signing by X or by Y or by Z”, to replace it.This will require to first obtain the signature of X or Y, which is notalways possible.

It is desirable to use a protocol as simple as Bitcoin but without thisdrawback. The proposed transactions consistency model (and protocol)overcome this limitation of Bitcoin.

The following introduction helps to identify the state of the artconcerning the present invention.

FIG. 1 schematically describes the essence of the (consistency) model ofBitcoin by presenting:

-   -   the OUTPUT of a first transaction (Tx1), with which are        associated:    -   a certain amount A (for Amount) of units of account, and    -   an address (#PubKey) to which the payment is made, this address        being the result of applying a given hash function to a public        key “PubKey”;    -   and the INPUT of a second transaction (Tx2), to which are        associated:    -   the said PubKey and    -   the signature (Sig_(PubKey)) that can be deciphered with the        same public key PubKey, of a content which includes the first        transaction (Tx1), the indication of its connected output (‘1’)        and the transaction Tx2 (Tx2 specifying this input and its own        outputs—note that the identifier of a transaction is the result        of a hash function applied to the contents of this transaction        except its inputs).

Hence, when an INPUT of a second transaction (Tx2) gets the amount (A)associated with an OUTPUT of a first transaction (Tx1), the generator ofthis second transaction necessarily knows:

-   -   the public key (PubKey) corresponding to the address (#PubKey)        associated with that OUTPUT,    -   and the private key (which she keeps secret) corresponding to        that public key (PubKey)—insofar as the signature        (Sig_(PubKey)(Tx1,1,Tx2)) associated with the second transaction        is the result of an encryption using her private key.

The interest of this model is to ensure firstly that the address #PubKeyis the only possible beneficiary of the amount (A) in question, andsecondly that the owner of that address cannot refute that she hasreceived that amount (A).

A transaction can have multiple inputs—each being connected to an output(and only one) of another transaction—as well as multiple outputs, thesum of the amounts taken by the inputs having to be equal to the sum ofthe amounts supplied by the outputs.

This model also allows to express conditional transactions, theconditions being signatures to be provided (an output of a transactioncan be spent if these signatures are provided). In general, this (knownas Pay-to-Script-Hash or #P2SH) is implemented as follows: instead of anaddress corresponding to a public key (#PubKey), an output may specifythe hash of the content of a script associated with the input which willbe connected to it. This is defined in BIT-16 Bitcoin ImprovementProposal[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki] and[https://en.bitcoin.it/wiki/Transactions#Pay-to-Script-Hash].

Thus, a transaction may transfer a certain amount of units of account toan MULTISIG address for which n of m signatures are required to spendthem—for instance, two signatures are to be provided among thesignatures of a supplier, a customer and an abiter (i.e. two out ofthree signatures, the arbiter's signature being needed in case of adispute between the supplier and the customer).

The transactions are validated against the consistency model presentedabove and then inserted into an immutable data structure (a linked listof cryptographic hashes), called blockchain. Thus, a transactioninserted (“commit”) in the blockchain may not be changed. The blockchainis shared and the Bitcoin protocol ensures that no output connected toan input in a downstream transaction will be connected to an input ofanother downstream transaction (no “double spending”).

The blockchain functions as a ledger reconstructing the history oftransactions and allowing anyone to verify them: when an individual Adoes a transfer of a number of units of account from one of itsaddresses to an address of an individual B, A must prove where theseunits of account come from. And so, it transmits information such as“these units of account are those I obtained when C sent them to me twodays ago.” And insofar as all users have the same copy of theblockchain, everyone can verify that C actually sent these units ofaccount A and they have not been sent by A to someone else. Further inthe chain, one can also check how C has itself obtained these units ofaccount and thus trace the chain of their successive owners. In otherwords, one can reconstruct the history of transactions and thereforetheir validity, provided that the initial transactions are valid. Thetransactions included in the blockchain being validated, there is nolonger need of a trusted third party or a chain of trusted third partiesas in the case of a network of financial intermediaries (the bankingsystem), so neither these intermediaries themselves.

The fact that, in the case of #P2SH, the address associated with anoutput (of an “upstream transaction”) is the result of applying a hashfunction to the content of a script associated with the input (of a“downstream transaction”) that connects to it, means that a largevariety of types of transactions can be expressed. An input may forexample specify an address which is the result of applying a hashfunction on a script including a sought content—meaning “I pay thisamount in exchange of a content for which I only give the hash code”—sothat anyone who knows the content in question (and who agrees todisclose it by putting it in the blockchain) can benefit from thisamount.

However, in the existing consistency model of Bitcoin, said script on aninput of a downstream transaction (connecting to the given #P2SH outputof an upstream transaction) has no effect on the outputs (of that samedownstream transaction). Indeed the Bitcoin protocol provides novalidation to check constraints that would relate to outputs of thedownstream transaction (constraints that would be provided in saidscript).

SUMMARY OF THE INVENTION

The present invention aims at filling this gap by extending theconsistency model described above and at enabling conditionaltransactions to be performed in a dynamic context of payment conditions,without requiring repeated signatures as described in the introduction.In other words, the invention aims at extending the possibilities of aBitcoin-type system to validate the transactions according to a newconsistency model.

It is thus proposed a transaction system based on a distributedpeer-to-peer computer architecture, said system involving transactionsgenerated by users by means of wallets and allowing the transfer ofunits of account by feeding inputs from outputs, each transaction(called downstream transaction) having an input directly or indirectlyreferring to an output of an upstream transaction (or several inputseach referring to an output of a respective upstream transaction) andhaving an output specifying the number of units of account and anaddress of a recipient, the system comprising:

-   -   means for connecting an input of a downstream transaction to an        output of an upstream transaction as a function of matching        rules between a code computed on all or part of the content of        the downstream transaction and a check code contained in the        upstream transaction, or conversely,

the system further comprising:

-   -   means for propagating a contract, predetermined at an upstream        transaction, to a downstream transaction having an input        connected to the output of said upstream transaction, said        contract being executable on a context for establishing        allocation constraints of the output(s) of the downstream        transaction, such allocation being authorized only if the        constraints are met.

Certain preferred but non-limiting aspects of this system are asfollows:

-   -   the addresses of the downstream transaction outputs are obtained        by a coding operation applied to the contract and a context.    -   the coding operation includes a hash code generation.    -   the predetermined contract is common to a plurality of upstream        transactions having outputs respectively connected to several        inputs of the downstream transaction.    -   the allocation of a downstream transaction output is authorized        if the allocation constraints corresponding to at least one of        the upstream transactions are met.    -   the allocation of a downstream transaction output is authorized        if the allocation constraints corresponding to all upstream        transactions are met.    -   the allocation constraints include possible output addresses.    -   the addresses correspond to multi-signatures.    -   the allocation constraints comprise maximum amounts of units of        account associated to output addresses.    -   the allocation constraints comprise transaction types.    -   the transactions are organized in pots associated to respective        users, and wherein the allocation constraints are defined pot by        pot.    -   the context comprises upstream transaction output identifiers,        so that said allocation constraints evolve dynamically as a        consequence of the addition of new transactions upstream of said        downstream transaction,        -   in such manner that the allocation of outputs of the            downstream transaction can be implemented with an evolving            group of users capable of generating upstream transactions            over time, without having to initially know said users.

It is proposed according to another aspect a method for minimal andanonymous identification of a user that can potentially benefit fromrights (advantage), comprising the following steps:

-   -   interacting with a source of rights from a user terminal,    -   at said source, communicating to the user terminal a        verification program (in ZK-SNARK) except if said user terminal        already contains such program, as well as a specific character        string representative of a validity period for benefiting from        the rights, or generating said character string by said program,    -   at said user terminal, executing the verification program for        anonymously proving its possession of an identity document, said        check program receiving as a private input machine-readable data        from said identity document and as a public input said specific        character string, and a hash code obtained by combining said        specific character string and the identity document data,    -   providing to the source of rights the hash code thus obtained        and a proof of execution of the verification program,    -   checking at said source said execution proof, and    -   delivering rights for the considered period of time,

wherein no relation between the hash codes obtained for one same userand allowing the latter to benefit from rights at different periods oftime can be established by said source of rights, whereby the useranonymity is preserved.

Finally, it is proposed a method as defined above, wherein the rightsare units of account as transacted in the system according to the systemas defined above.

BRIEF DESCRIPTION OF THE DRAWINGS

Other aspects, aims and advantages of the present invention will betterappear from the following detailed description of preferred embodimentsthereof, given by way of non-limiting example and with reference to theappended drawings, in which:

FIG. 1 illustrates two types of Bitcoin transactions and theirconsistency model,

FIG. 2 shows three transactions and additional elements to implement thenew consistency model according to the invention,

FIG. 3 illustrates how a Bitcoin type of transaction can be representedby two transactions linked by a constraint,

FIG. 4 is a sequence diagram illustrating interactions between differentactors (wallets) in a method according to the invention,

FIG. 5 shows the creation of new transactions according to the inventionwhen a new actor of a certain type participates in a pooling of risksbetween actors,

FIGS. 6 and 7 illustrate generalizations of what is illustrated in FIG.5,

FIG. 8 schematically shows an example of networked pooling of risksusing a second embodiment of the invention,

FIGS. 9 and 10 illustrate the automatic generation of rights, such asunits of account transferred in transactions illustrated in previousfigures.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The consistency model implemented according to the present invention isdiagrammatically shown in FIG. 2. An indirection (or multipleindirections), represented as a transaction Tx2 between a fundingtransaction Tx1 and a payment transaction Tx3 (respectively multiplepayments), allows a degree of freedom in the payments due to the factthat now payments are constrained with respect to a common executablecontract (Contract) that must be interpreted according to the currentcontext (Context1, Context2), these constraints being generated byexecuting the said contract, which is executable as a computer program,by taking said current context as input.

Compared to FIG. 1, FIG. 2 now shows that:

-   -   the address on the output of the Tx1 transaction is not        determined by the key(s) PubKey(s) of the beneficiaries, but by        the context (Context1) at the time of the generation of this        transaction Tx1, as well as by the content of the contract        (Contract),    -   the first output of the Tx2 transaction allows payment to        beneficiaries (same payment as the output of Tx1 in FIG. 1),    -   and, as for the output of Tx1, the address on the second output        of Tx2 is determined by the context (Context2) at the time of        the creation of this transaction Tx2 and the content of the same        contract (Contract).

For each transaction (take for example Tx2), in addition to traditionalverifications specified in the Bitcoin protocol, before insertion intothe blockchain (these verification essentially consisting in controllingthe inputs of the transaction in question (Tx2) against the upstreamoutputs (of Tx1) as described in the preamble), the validity of theoutputs of the transaction in question (Tx2) is also verified vis-a-visthe contract applied to the context (Context1).

Note that Tx2 can have inputs connected to multiple upstreamtransactions of the type Tx1 or Tx2, and that several Tx2 type oftransactions can be generated in the chain, thus allowing severalpayments. The method of the invention consists in validating the outputsspecific to each transaction according to the consistency modelpresented in FIG. 2. As already indicated, the purpose is to validatetransactions between each other, like in Bitcoin before insertion intothe blockchain but this validity now depends, in addition, on thecompliance of the transaction with the application, on the currentcontext, of the unique executable contract binding the parties. Due tothe inclusion, in the output of the upstream transaction, of theverification code (such as a hash-code) of a content explicitlycontaining the contract (or a hashcode of that contract) associated withthe downstream transaction, the method of the invention ensures that alltransactions of a chain of transactions (such as Tx1, Tx2, Tx3) applythe same contract.

We will now present two main embodiments of the method of the inventionand detail these validations.

First Embodiment

First we introduce the concepts of “contract” and “context”, theapplication of a contract on a context resulting in “constraints”.

As mentioned in the preamble, it has recently been introduced in Bitcoinan option to specify the condition of an output by placing in it thehash of this condition (called «Pay to Script Hash» or #P2SH), whichmust be provided in clear in the input of the transaction that uses thisoutput (and this condition must be satisfied for that transaction to bevalid). To date, the conditions that can be expressed in Bitcoin aremerely conditions of multi-signatures to be provided in said input. Wewill use this method in the following examples.

The left side of FIG. 3 presents an example thereof:

A transaction “Tx1” provides 1000 units of account to a recipient nodeidentified by a hash code referred to as “C1”, these 1000 units can onlybe consumed by an input with a script whose hash code (obtained byapplying a predetermined hash function on its content) is that C1, thatinput including signatures that meet the condition specified in thatscript.

As for the right part of FIG. 3, it presents exactly the same payment ason the left side (i.e. 1000 units to C1) but it introduces anindirection according to the method of the invention:

The 1000 units are, in a first transaction (called upstream transaction)“Tx1.1”, paid to a receiving node “P1” (so-called Pot), from which, in asecond transaction (called generated transaction or downstreamtransaction) “Tx2.1”, the payment of 1000 units must comply with aconstraint represented by “1000@C1” (meaning that it must provide 1000units to C1) imposed by the first transaction implicitly or not (thus inthe figure, the constraint is shown on the output of the upstreamtransaction, in italics).

More specifically, P1 is a verification code obtained by applying apredetermined function to the script of the input of Tx2.1, and Tx2.1must comply with the constraint (here the constraint 1000@C1) producedby the script of this input. (How this constraint is produced isdescribed later.)

Note that, as we shall see later (for example in FIG. 5), a generatedtransaction can have multiple inputs and to be valid it has to complywith a constraint issued by one of its inputs.

In the following we will take the example of suppliers (F_(i)) which, intransactions (Tx1.i), lock units of account that cannot be unlockedunless (according to a condition C_(i)) the customer (for that C_(i))and the supplier both sign the transaction, or the “arbiter” (or“arbitrator”) signs the transaction with the supplier. The lockings(with these signature conditions) are intended to assure the respectivecustomers that if they are not delivered satisfactorily, the units ofaccount that have been locked will be returned to them.

In a “risk pooling” approach, suppliers are organized in a “community”and use the method of the invention to deposit (lock) units of accountin a pot, the commitments by the suppliers to the customers being thusdone through the pot rather than directly by each one. Thus, theprobability of having to pay a customer being less than 1, the more thepot is filled, the lower the amounts locked by the respective suppliers.

The term “locking” is used here to highlight that these deposits aretransactions inserted into the blockchain to ensure that the depositedunits of accounts (from an upstream output) cannot be double-spent (butpossibly returned further downstream in the case of a multi-signatureC_(i) permitting it).

Note that depending on the community at stake, the aforementionedarbiter (having the role to provide the second signature in case of twoof three signatures needed) may need to be approved by the community(for the downstream transaction to be able to be validated). Moreover,the frequency of interventions may be limited (as a precaution).

In FIG. 3 (and in the following figures), the verification code “Pot” isthe hash code of the script content of the input of a generatedtransaction, the script allowing to generate constraints such as 1000@C1that will be checked in relation to the outputs of said generatedtransaction. These constraints are generated by execution of a programcalled contract (or “community contract” that binds the communitymembers at stake as far as the locking modalities and downstreamtransactions generation are concerned) on parameters called invocationcontext (or context). Both the contract and the context belong to theinput of the generated transaction.

The various suppliers are mutually constrained regarding their lockingsbecause they share the same contract and, for all the lockings by themembers of a given community, the transactions Tx2 i are generated bythe application of the same contract. In other words, only thosetransactions that conform to the contract are valid.

Said contexts contained in the input are signed by the community. In aparticular embodiment, it can be a multi-signature (by n among mcommunity members) or a signature by a computer in “trusted computing”mode. In trusted computing systems (which is a known technology), thecomputer has a pair of public/private keys is, the private key beingwritten in the hardware without any possibility of external reading,hence being is kept secret, and can be used to sign on behalf of thecommunity.

Since the programs that are executed in a trusted computing system canbe authenticated (by generating hash codes for these programs andsigning them with the aforementioned secret private key, a techniqueknown as “remote attestation”), this approach allows not only to check(by comparing the hash) that it is the correct code that is executed,but also to secure the data sent to the program by encrypting it withthe public key corresponding to aforementioned secret private key, andbe sure of the integrity of the signed results returned. Such programscan thus be used to implement a protocol for the functioning of acommunity such as described later and presented in a sequence diagram inFIG. 4.

In summary, the transactions according to this embodiment arecharacterized in that they contain the following elements:

-   -   In the output of the upstream transaction:    -   i. Value: number of units of account    -   ii. Hash(Contract+Context): hash code «Pot» (like the        «[20-byte-hash-value]» of «OP_HASH160 [20-byte-hash-value]        OP_EQUAL» of BIP 16) resulting from applying the predetermined        hash function to the content of the script of the input in        question of the generated transaction,    -   In the script of the input of the generated transaction:    -   i. Contract,    -   ii. Signed invocation context related to the connected output.

Validation consists in:

-   -   verifying that all the inputs of the generated transaction        include (in their respective scripts) the same contract, as well        as the signature (or multi-signatures) of the supplied        invocation context by the community;    -   obtaining the hash code of the script content (Contract+Context)        of each input of the generated transaction and compare it with        the hash code provided in the output it connects to and make        sure they are identical, and    -   executing said contract on the said invocation context relative        to the connected output, in order to:

1. obtain the constraints (constraining outputs), and then

2. verify that for one input of the generated transaction the obtainedconstraint is satisfied by the outputs of the generated transaction(this will be illustrated in the examples below).

The verification succeeds with just one compliant input (that is to say,it is sufficient to satisfy the constraints issued by a single connectedoutput), since a generated transaction cannot comply with theconstraints issued by an upstream transaction earlier than its ownupstream transaction; indeed it can (as far as it benefits from anassistance) have an input benefiting thereof (as will be described inthe following example presented in FIG. 5).

We will now illustrate the generation of a community and describe howthe pooling of risk is achieved. In the following example, the principleis that the first supplier (or one or more substitutes) plays acoordinating role (Root) and informs the other suppliers about thecontext, according to the protocol shown in FIG. 4. The context thuscommunicated to successive members of the community includes the currentset of outputs available in the pot (corresponding to the previousdeposits or a subset thereof as will be seen in an example shown later),to which payments (to be generated as per the contract) may connect, theremainder of units of account taken from these outputs being put back tothe pot for the next payments. Each supplier can thus complementpayments from other suppliers in case their commitments to theircustomers are not fully covered.

FIG. 4 is a sequence diagram showing the interactions between thedifferent actors involved. ‘F_(n)’, and ‘F_(n−1)’ are suppliers, ‘C_(n)’and ‘C_(i)’ are customers, ‘Blockchain’ represents the network: an arrowto ‘Blockchain’ indicates announcing one or more transactions in thenetwork to have them included in the Blockchain. ‘Root’ is the communityinitiator, the first supplier, or a set of other suppliers when thecurrent root isn't functional (e.g. the current root leaves thecommunity, or becomes unavailable). Interactions are represented herewithout specifying whether they are carried out manually orautomatically (the value of automatic processing is presented justafter). The numbers in the figure correspond to the following steps:

1. A new supplier ‘F_(n)’ is introduced in the community by the supplier‘F_(n−1)’ which communicates the ‘Root’s address (or new contribution isrequested by an existing supplier)

2. ‘F_(n)’ requests confirmation from ‘Root’ by providing the identifierof ‘F_(n−1)’ (typically can be added here sub-steps of validation of thenew member's entry into the community and of insertion into the contextof special parameters, such as the volume of outputs available in thepot to be considered for this new member)

3. In case of confirmation, ‘Root’ provides the current state of thecommunity containing in particular all (or a subset of) availableoutputs with their own respective contexts (to allow a new input toconsume them)+the set of values (number of units of account) expected bythe respective customers, the available outputs and the expected valuesrepresenting essential elements of the context used in point 4

4. ‘F_(n)’ hashes the contract and the context to generate the hash thatwill appear in the output of its deposit (Tx1.n)

5. ‘F_(n)’ announces its payment (Tx1.n) in the network

6. ‘F_(n)’ generates the constraints and the corresponding transactionsand accordingly sends to ‘Root’ an update of the context

7. ‘F_(n)’ may itself inform its customer ‘C_(n)’ about the transactionswhich are made available

8. ‘F_(n)’ may itself inform the other customers about the transactionsthat they will potentially benefit.

One can of course consider a system to assist suppliers (or other typeof entities, as mentioned later) to generate constraints andtransactions and to assist customers (or other potential beneficiariesof these transactions) to also generate transactions as appropriate toget paid and in due time to announce these transactions in the networkand make their insertion in the blockchain.

The contract can be designed to take account of requirements andpreferences (provided in the context), particularly as to the volume ofthe amounts provided potentially payable by the generated transactions(i.e. to ignore some deposits in the pot and exploit others) andconstraints produced accordingly, as seen in the example presentedbelow.

The right side of FIG. 3 presented the deposit in the pot of 1000 unitsof account by a first supplier (following the creation of a newcommunity and its contract). FIG. 5 shows in addition the transactionsadded for a second supplier. We see in this figure four lines oftransactions, corresponding to the consumption order of the outputs ofthe first transactions Tx1.i. Thus, for the case of delivery defects bytwo suppliers, F1 and F2, for two respective customers, C1 and C2, thefirst line of transactions shows the case of a first payment to C1 by F1in case of delivery default by F1 to C1, the second line is for the caseof payment to C1 by F1 after C2 was paid in case of successive deliverydefects, the third line shows the case of a first payment to C2 in caseof delivery default by F2 to C2, and the fourth line shows C2 payment byF2 after payment to C1 has already been done. Restitution to suppliersof amounts locked (in case deliveries were carried out properly) followsthe same process, the beneficiaries of transactions being in this caseF1 or F2 instead of C1 or C2. So, by the C_(i) we mean, rather than thecustomer, the conditions (multi-signatures) for a payment to thecustomer or supplier of level i.

The constraints are presented here in a compact syntax for specifyingthe amounts and the recipients nodes. Thus, on Tx1.2,950@(950@C1)&1000@C2 and 950@C2 form a constraint (which can berepresented as 950@(950@C1)&1000@C2//950@C2) meaning “generatedtransaction having a first output paying 950 units of account(implicitely into the Pot) from which another generated transaction pays950 units of account to a condition C1 and a second output paying 1000units of account to a condition C2, and a generated transaction havingan output paying 950 units of account to a condition C2”.

The addition of a new locking to the pot allows complementing thetransactions that did not pay the total amounts expected by thecustomers. For instance, as far is the sequence “C2 C1” is concerned(meaning first ‘C2 or F2’ is paid, then ‘C1 or F1’ is paid), Tx2.2.2pays only 950 units of account while the customer C1 possibly expects toreceive 1000.

FIG. 6 shows a way to generalize the process and facilitate theimplementation of a contract, a (simplified) example of which beingpresented (encapsulated between tags in the XML formalism) in Annex 1.Compared with FIG. 3, in FIG. 4 the generated transaction Tx2.2.3 isconnected to an output of the generated transaction Tx2.1.1 instead ofbeing connected to an output of the deposit (Tx1.2) by F2, which itselffeeds Tx2.1.1 although the latter was already sufficiently fed by Tx1.1.This way, the mechanism works regardless of the amounts locked bydifferent vendors. For example Tx1.1 may consist of a locking lower thanthe amount expected by C1 (pending other suppliers participating in thepot and complement its deposit).

FIG. 7 shows the principle of the method thus generalized, withconditions on amounts A_(i) deposited by suppliers F_(i) vis-à-vis theexpected amounts A_(i)r (for Required Amount) by customers C_(i), todetermine the amounts to be specified on outputs, as implemented in theprogram given in Annex 1 as a simplified example. Thus, (the firstoutput of Tx2.1.1, after the introduction of F2)“A1+A2>A1r:A1r,(A1+A2)→A1r→1000” means «If A1 (i.e. the deposit byF1)+A2 (i.e. the deposit by F2) is greater than A1r (i.e. the expectedamount C1), then the output pays A1r (here this is the case, and theoutput therefore pays 1000 units of account) else the output pays A1+A2.

By the program presented in Annex 1, for the following context (wherethere are 3 suppliers F1, F2, F3, these suppliers depositingrespectively 1000, 950 and 900 units of account, and their respectiveclients C1, C2, C3 each waiting for 1000 units of account)

List<Output> availableOutputs = new LinkedList<Output>( ); availableOutputs.add(new Output(1000,“F1”));  availableOutputs.add(newOutput(950,“F2”));  availableOutputs.add(new Output(900,“F3”));List<ClientRequirement>     currentRequirements     =     newLinkedList<ClientRequirement>( );  currentRequirements.add(newClientRequirement(1000, “C1”));  currentRequirements.add(newClientRequirement(1000, “C2”));  currentRequirements.add(newClientRequirement(1000, “C3”)); the following constraints (to whichgenerated transactions must respectively comply) are generated:1000.0@C184850.0@((1000.0@C2&850.0@(850.0@C3))11(1000.0@C3&850.0@(850.0@C2)))1000.0@C284850.0@((1000.0@C1&850.0@(850.0@C3))11(1000.0@C3&850.0@(850.0@C1)))1000.0@C384850.0@((1000.0@C1&850.0@(850.0@C2))11(1000.0@C2&850.0@(850.0@C1)))

As to the (simplified) context presented in Annex 2, context provided toF5, it includes the outputs from the suppliers F1 to F4, and F5restricts the generated constraints to a total amount of contributionsof 2000 units of account and 2 contributions at least (in this example),as we see hereafter in the function call

« generateConstraintsAutoSelectOutputs(f5, availableOutputs, c5,2000,2);».  Output f1 = new Output(1000, “F1”);  Output f2 = new Output(950,“F2”);  Output f3 = new Output(900, “F3”);  Output f4 = new Output(850,“F4”);  Output f5 = new Output(800, “F5”);  ClientRequirement c1 = newClientRequirement(1000, “C1”);  ClientRequirement c2 = newClientRequirement(1000, “C2”);  ClientRequirement c3 = newClientRequirement(1000, “C3”);  ClientRequirement c4 = newClientRequirement(1000, “C4”);  ClientRequirement c5 = newClientRequirement(1000, “C5”);  List<Output> availableOutputs = newLinkedList<Output>( );  Pledge p1 = new Pledges; p1.addClientRequirement(c1);  Pledge p2 = new Pledges; p2.addClientRequirement(c2);  Pledge p3 = new Pledges; p3.addClientRequirement(c3);  Pledge p4 = new Pledges; p4.addClientRequirement(c4);  Pledge p5 = new Pledges; p5.addClientRequirement(c5);  f1.setExistingPledge(p1); f2.setExistingPledge(p2);  f3.setExistingPledge(p3); f4.setExistingPledge(p4);  f5.setExistingPledge(p5); availableOutputs.add(f1);  availableOutputs.add(f2); availableOutputs.add(f3);  availableOutputs.add(f4);  List<Constraint>lc = generateConstraintsAutoSelectOutputs(f5, availableOutputs,c5,2000,2);  for (Constraint c : lc) {   System.out.println(c);  }

This program (also simplified) generates the following constraints(which generated transactions must respectively comply):

1000.0@C5&1550.0@((1000.0@C4&550.0@(550.0@C3))||(1000.0@C3&550.0@(550.0@C4))) 1000.0@C5&650.0@(650.0@C4) 1000.0@C5&700.0@(700.0@C3) 800.0@C5

Note that this program only generates downstream transactions receivingcontributions from previous suppliers (suppliers F1 to F4 do not receivecontributions from F5).

These programs can easily be extended by the skilled person forgenerating transactions themselves.

In a variant of this embodiment, the invocation Context and/or theContract can be placed on the output of the upstream transaction, thereceiving node still being represented by the hash of the invocationContext and the Contract, or represented by the hash of the Contractonly. However, the fact that the system works with this variant must bedetected, in order to, at validation phase, produce the constraints byexecuting the contract on the context and to verify that the outputssatisfy them (as already described). This detection can be accomplishedfor example by placing in the output in question the information thatthe system operates according to this variant.

These methods may be combined, each output containing information of theconsidered mode, explicitly or implicitly.

The generated transactions can possibly be “locally” validated. In thiscase, the generated transactions are conditional transactions of thetype Pay-to-Script-Hash (classically). In each generated transaction,the signature of its validity by the community—by that we mean amulti-signature or the signature of a trusted computing computer—mustthen be added (before broadcasting it to have it included in theblockchain). It is understood that it is then not necessary to keep inextenso the content of inputs, if the validators (via Root) are capableof rebuilding and checking the outputs of the generated transactions.The limit of this approach is that any transaction authorized by thecommunity can tap into a supplier F_(n)'s deposit. So it is better toimplement the entire protocol shown in FIG. 4, because it is indeed acontract between F_(n) and the community (represented by Root) and thisprotocol allows F_(n) to generate constraints themselves on the basis ofthis contract and the current context, in agreement with the community,and to ensure that they will be respected. It follows that the mostadvantageous approach to this embodiment is to make the signature of thecommunity verified by the network (signature provided on the transactionand indicating that the generated transaction has already been verifiedby the community, locally, as mentioned above) with regard to thesignature of the invocation context provided in each input (by comparingthe public keys corresponding to the private keys that were used tosign). We then have the assurance that F_(n) and the community are inagreement.

A variant of this first embodiment based on zero-knowledge prooftechniques will now be described.

In the article «SNARKs for C: Verifying Program Executions Succinctlyand in Zero Knowledge» (http://eprint.iacr.org/2013/879, the content ofwhich is part of the present description) Eli Ben-Sasson et al. describetheir work on correct execution zero-knowledge proof for programswritten in C. According to these results, a program can be executed in aspecial environment which allows to obtain a succinct proof, that can beverified in a very short time, of (i) the integrity of the program thatwas executed (that is to say, the proof that the program has not beenaltered) et (ii) its correct execution. Moreover, the execution of thesaid program can also be done by taking in input private data which isnot disclosed.

An embodiment of this variant includes specifying, in the output of theupstream transaction, a verification code of the correct programexecution's (zero-knowledge) proof, and the proof itself must be presentin the input of the generated transaction that connects to this output.Here the said program is the contract and the data supplied to it is theinvocation context and the outputs of said generated transaction.

Compared to the first embodiment described above, here the programforming the contract (whose execution proof is provided in an input ofthe generated transaction) is slightly different in the sense that theconstraints produced by its execution are directly verified (during thatexecution) on the outputs of the generated transaction containing thatproof in an input, whereas in the previous embodiment, only constraintsare generated by the contract, which is applied on the context, then theverification is made separately from the program.

In this approach, the verification code is analogous to the hashdescribed above, but the advantage of this approach is that thevalidation of the constraints (constraining the output of the generatedtransaction) can be accomplished only once (just to provide this proofonce). Insofar as verifying the proof takes much less time thanexecuting the contract on the context and verifying the constraints onthe outputs of the generated transaction, generating that proof onlyonce may be more advantageous (although that proof generation may take aconsiderable time) than re-executing the contract n times to validate byn signatures a generated transaction (if one would wish that nvalidators verify every transaction generated—rather than Root only—tovalidate it on behalf of the community).

In general, the method of the invention according to this embodiment canbe applied to any case of risk of pooling.

The invention has been described by taking an example of a deposit ofunits of account by a supplier to reassure a customer, but one can ofcourse also apply the same method for the case of a customer depositingunits of account to reassure a supplier, the same advantage of pooling(typically of risks pooling) existing in the case of pooling betweencustomers.

One can also pool risks of illness or accident and lock units of accountto cover medical treatment expenses, etc. Also it is not only aboutcovering suppliers or customers but any type of actors, who one the oneside poll each other and on the other side accept to receive guaranteesby a community of such polled actors.

Note also that this first embodiment of the invention applies toarchitectures where downstream transactions refer directly to upstreamtransactions (eg the Bitcoin system) as well as to architectures wherethis reference is indirect (e.g. the Zerocash system based onzero-knowledge proof, enabling non-disclosure of the origin of units ofaccount). The skilled person will in this case know how to make thenecessary adjustments.

Second Embodiment

A second embodiment of the method of the invention will now bedescribed, which also consists in validating each transaction based onthe consistency model shown in FIG. 2, but additionally based (in thecontext) on the specification of transaction types and input parametersthey admit, thus constraining the outputs of the downstream transactionin a particular manner.

FIG. 8 diagrammatically depicts a networked risk-pooling example usingthis embodiment.

In this embodiment, the blockchain is structured in different “pots”,each associated with an individual user terminal and to the damage riskthat this user can be exposed to. Each transaction can have inputsconnected to several upstream transactions from different pots andseveral transactions can be generated on a same pot e.g. to allowmultiple payments.

In the example shown in FIG. 8, users:

-   -   each have a pot that they feed through «Refill» transactions;    -   specify «Potential Contribution» transactions to other users        should a damage occur to them;    -   generate, when a damage occurs, «Actual Contribution»        transactions from the users' pots which have issued Potential        Contribution transactions;    -   at last generate final payment transactions “Claim” or “Claim        Payment”).

A special case of transaction in this embodiment consists in aggregatingoutputs from transactions which are on different pots in the blockchain.The “Claim” transactions are in this case; they have inputs connected tooutputs of transactions on different pots, to provide, in their ownoutput, the sum of their amounts.

In FIG. 8, the pots (Pot1, Pot2 and Pot 3) are represented in dashedlines. The «Potential Contribution» transactions generate branches inthick grey lines from the pots, on which pot aggregation transactions(#Claim) can be placed.

FIG. 8 shows an example where three pots each receive 925 units ofaccount locked by a “Refill” transaction. The first and third pots eachcreate a “Potential Contribution” type transaction to cover the riskassociated with the second pot for up to 925 units of account. A damageactually occurs at the second pot, this damage implying a payment of 600units of account to be made. Then the user terminal (that may be called“wallet” in the bitcoin jargon) associated to the second potautomatically generates “Actual Contribution” type transactions, eachfor 200 units of account, on the three pots, namely: its own pot and theother two pots that have issued a “Potential Contribution” transactionfor the second pot. Finally, the same “wallet” generates the “Claim”payment transaction of 600 units of account to settle this damage.

The system as thus implemented allows generating transactions forlocking units of accounts in pots, declaring mutual help from these potsand actual payments in case of damage, that can occur at any time butthat must comply with the constraints imposed by the contexts implicitlyspecified in the outputs of the upstream transactions, these constraintsresulting from the application on these contexts of the common contractused to generate the outputs of a downstream transaction.

More specifically, each constraint indicates, for each pot, theauthorized downstream transaction types and the parameters (such as theamount not to be exceeded) that the contract execution must take asinput to generate the outputs of these transactions (Cf. Annex 3).

Thus it is seen in FIG. 8 that the first transaction on the first pot,which is of the “Refill” type, implies that only a transaction of type“Potential Contribution” (for up to 925 units of account), of type“Refill” or of type “Actual Contribution” (for up to 925 units ofaccount) can be generated at its downstream and only in the same pot.The second transaction in the first pot, which is of type “PotentialContribution”, imposes that exclusively (i.e. no pot other than thefollowing ones can be generated at its downstream):

-   -   on the first pot, as in the previous transaction, only a        transaction of type “Potential Contribution” (for up to 925        units of account), of type “Refill” or of type “Actual        Contribution” (for up to 925 units account) can be created at        its downstream;    -   on the second pot, only a transaction of type “Actual        Contribution” (for up to 925 units of account) can be generated        at its downstream.

And so on, each transaction thus restricting the set of transactionsthat can benefit from the units of account specified on its outputs.

Finally, it should be noted that the two embodiments presented hereinenable “networked” risk sharing. Let's take an example and suppose thattwo users each have a small house, think that the likelihood of a fireis very low and would cost 10,000 units of account. They decide to hedgefor this amount and put 5,000 units of account each in a pot for thispurpose, as described above. Suppose a friend also has a small house anddecides to join them. He puts 3,333 units of account in his pot and sothe first two users can withdraw 1,666 units of account each. And so on. . . Their common contract of risk sharing in P2P does not require anyfinancial intermediary. Obviously, if there are other users who jointhem, they will certainly have some expenses to pay an arbiter(arbitrator), validator or mediator, confirming that the fire was notintentional, etc. but without requiring an intermediary that would keepthe amounts locked. Finally, another characteristic advantage ofnetworked risk sharing is that when ‘n’ people connect to share therisk, the ‘n+1’th person does not need to connect with the ‘n’ first butwith some of them only. We thus obtain a social network, where theconnections of each one may be different. This type of structure islikely to be extended much more widely than with a centralized riskpooling.

Another Object of the Invention

Another object of the invention relates to the automatic generation ofrights, including units of account like the ones transferred bytransactions of the types described above.

The state of the art concerning this object of the invention isdescribed in the article «Verifying computations without reexecutingthem: from theoretical possibility to near practicality»http://eccc.hpi-web.de/report/2013/165/download/, and in theaforementioned article http://eprint.iacr.org/2013/507.pdf publishedOct. 7, 2013, by Eli Ben-Sasson & al. proposing a system able to provethe execution of a program that can take private data in input (privateinput), without revealing it. These are programs written in C, but themethod can be generalized to any programming language. In the following,such a program executed in this special environment is called “ZK-SNARKprogram” or “ZK-SNARK verification”. The system is zero-knowledge forthe given private input. Initially, this work was based on the work ofShafi Goldwasser, Silvio Micali and Charles Rackoff in the 1980s(http://en.wikipedia.org/wiki/IP_%28complexity%29#PSPACE_is_a_subset_of_IP).

An application of this new technology, presented in FIG. 9, is to provethe possession of an electronic passport without revealing its contents.The program is taking, as private input, by NFC, the (signed) datacontained in the electronic component of the passport (cf. the ICAOdocument which specifies that datahttp://www.icao.int/publications/Documents/9303_p3_v2_cons_en.pdf), andtakes in public input the public key (of the government, or severalpublic keys) that allowed to sign that data. The ZK-SNARK program hereis used to verify that it is a passport supplied by said signatory (i.e.by the government).

The invention, according to this other object, is an extension of themethod used in this application, and is intended to meet the need to“minimally” identify an anonymous individual (user) to which certainbenefits (or “rights”) are given to a limited extent over time, toverify that the user has not already received these benefits too much ortoo recently and therefore the user is still entitled to it. The term“minimally” here is related to the notion of anonymity: the inventionaims to safeguard the anonymity of the user as much possible whileensuring she does not receive benefits to which he is not entitled.

In one possible implementation, one can extend the aforementionedapplication (presented in FIG. 9) of proof of passport, by adding inpublic input the passport hash code (code obtained by using apredetermined cryptographic hash function on the content of passportdata or a specific part of the passport data) which must also beverified by the program in ZK-SNARK (in addition to the governmentsignature verification). No data of the passport being disclosed, theuser is merely identified by this hash code rather than the passportnumber for example. This identification is, however, not “minimal”insofar as the identifier (said hash code) can be linked to other datathat accumulate over time in data bases and, by overlap, tend to revealmore and more private information about the user.

Instead of the hash code of the passport, this object of the inventioninvolves using a hash code that is “minimal” in that it serves onlyduring the time when the user is entitled to a particular benefit. Incase the user has no right to benefit more than the benefit intended fora given time interval (from the last time she has received itpreviously), or for a given calendar period (such as the current monthor the current time) said hash code is used only during this timeinterval or this calendar period (specifically to check that the benefitin question has not already been given in this interval or period). Asit then becomes obsolete and replaced by another code, and there is norelationship between different codes obtained in time for the same user,the new code will not be connected to information characterizing theuser outside said interval or period.

Note that if the hash code is supposed to represent a right for a periodof time, the user may require it to be different for each period andcheck it.

FIG. 10 is a diagram showing the method of the invention. This methodcan be implemented with only the actors ‘user’ and ‘source’ (i.e. thesource of the benefit in question), that is to say, the respectivecomputers used by them, without the need of a trusted third party. Theverification protocol using this code includes the following steps ofinteraction between these players:

1. The user requests to the source the benefit in question and providesthe public key(s) of the signing authority of his passport (unless theZK-SNARK program contains in itself the public keys of the authorities,in which case the user does not have to provide it)

2. The source verifies said signing authority (unless the ZK-SNARKprogram contains in itself the public keys of the authorities and canthus at runtime make this verification without such input) andcommunicates to the user the ZK-SNARK program (unless the user hasalready it) and a specific string representative of a period (orinterval) of validity of the benefit in question (unless that programautomatically generates it)

3. The user generates the concatenation between said specific string andthe data contained in the component of this passport and executes saidprogram to prove its possession of an electronic passport (withoutrevealing its contents) signed by the said authority, by providing:

-   -   in private input, by NFC, the data contained in the component of        this passport    -   in public input    -   i. the public key(s) (of said authority) corresponding to the        keys that allowed to sign the passport data (unless that program        contains in itself the public keys of the authorities)    -   ii. said specific string (unless the said program automatically        generates it)    -   iii. and the hash code of the concatenation of said specific        string and data contained in the component of the passport.

and provides to the source said hash of the concatenation, and theZK-SNARK proof (in zero-knowledge) that:

-   -   it is indeed a passport provided by the authority and    -   said hash of the concatenation is obtained by applying the hash        function on the concatenation of said specific string and data        contained in the component of the passport.

4. The source verifies the said ZK-SNARK proof and, depending on the usecase, also verifies, where appropriate, the non-existence in itsdatabase of said hash of the concatenation and if that is the case,inserts the hash code of the concatenation into its database (where itcan be removed after the said period or interval of validity ofreceiving the benefit). The same process can be applied to cover aperiod of time where the user is continuously entitled to a particularbenefit.

Said specific character string can for example be made of the currentdate, the period covered (or the interval during which the benefit isnot due) and optionally a code (such as a random number or a specificinformation) for that period (or that interval).

Of course, several embodiments enable to implement the method of theinvention. In a simpler variant, the specific string is notrepresentative of a period of time but simply (or specific to) thesource of rights, possibly concatenated with a random number.

The benefits in question may be in particular units of account.

1. A transaction system based on a distributed peer-to-peer computer architecture, said system involving transactions generated by users by means of wallets and allowing the transfer of units of account by feeding inputs from outputs, each transaction (called downstream transaction) having an input directly or indirectly referring to an output of an upstream transaction (or several inputs each referring to an output of a respective upstream transaction) and having an output specifying the number of units of account and an address of a recipient, the system comprising: means for connecting an input of a downstream transaction to an output of an upstream transaction as a function of matching rules between a code computed on all or part of the content of the downstream transaction and a check code contained in the upstream transaction, or conversely, the system further comprising: means for propagating a contract, predetermined at an upstream transaction, to a downstream transaction having an input connected to the output of said upstream transaction, said contract being executable on a context for establishing allocation constraints of the output(s) of the downstream transaction, such allocation being authorized only if the constraints are met.
 2. The system according to claim 1, wherein the addresses of the transaction outputs are obtained by a coding operation applied to the contract and the context.
 3. The system according to claim 2, wherein the coding operation includes a hash code generation.
 4. The system according to claim 1, wherein said predetermined contract is common to a plurality of upstream transactions having outputs respectively connected to several inputs of the downstream transaction.
 5. The system according to claim 4, wherein the allocation of a downstream transaction output is authorized if the allocation constraints corresponding to at least one of the upstream transactions are met.
 6. The system according to claim 4, wherein the allocation of a downstream transaction output is authorized if the allocation constraints corresponding to all upstream transactions are met.
 7. The system according to claim 1, wherein the allocations constraints include possible output addresses.
 8. The system according to claim 7, wherein the addresses correspond to multi-signatures.
 9. The system according to claim 1, wherein the allocation constraints comprise maximum amounts of units of account associated to output addresses.
 10. The system according to claim 1, wherein the allocation constraints comprise transaction types.
 11. The system according to claim 10, wherein the transactions are organized in pots associated to respective users, and wherein the allocation constraints are defined pot by pot.
 12. The system according to claim 1, wherein the context comprises upstream transaction output identifiers, so that said allocation constraints evolve dynamically as a consequence of the addition of new transactions upstream of said downstream transaction, in such manner that the allocation of outputs of the downstream transaction can be implemented with an evolving group of users capable of generating upstream transactions over time, without having to initially know said users. 